1. Field of the Invention
Embodiments of the present invention relate to tools for the automated design of computer processor architectures.
2. Related Art
In contrast to general purpose computer systems, e.g., a desktop computer, which generally utilize a stand-alone microprocessor integrated circuit, the vast majority of computer-controlled or operated systems, e.g., mobile phones, hand held computers, electronic gaming machines, digital cameras, digital music players, embedded controllers and the like, utilize a form of integrated circuit known as or referred to as a system on a chip, or application specific integrated circuit (ASIC). In addition to a microprocessor or microcontroller, such an application specific integrated circuit typically comprises additional circuitry related to the function it is to perform, for example, for a mobile phone application, a system on a chip may comprise a digital signal processor and a display controller in addition to a microprocessor.
The design of such a system on a chip is greatly aided by the availability of “off-the-shelf” blocks for major functions. For example, well-known microprocessors, e.g., a variety of microprocessor cores, commercially available from MIPS Technologies, Inc. of Mountain View, Calif., under the trademark MIPS® Pro Series, are available as “IP blocks” (intellectual property blocks). Many other processors and functions are available as IP blocks from a wide variety of suppliers. An ASIC designer is able to combine such IP blocks to create a customized integrated circuit targeted to a specific application.
The providers of programmable intellectual property blocks, for example, blocks that implement a programmable function, e.g., microprocessors and digital signal processors, are increasingly enabling their customers, e.g., ASIC designers, to enhance the instruction sets of such processors. By adding instructions to a base set of instructions, an ASIC designer may be able to beneficially improve execution of complex algorithmic kernel functions characteristic of the application, e.g., digital audio playback.
For example, based on application profiling results of the main central processing unit (CPU), a designer is able to identify time-critical “hot-spots” of an application. Such “hot-spots” are analyzed and partly transformed into a special purpose instruction hardware implemented by the designer. In contrast to traditional co-processors, such custom instruction-set extensions are seamlessly integrated into the main CPU's software flow. Thus, from an embedded software developer's perspective, the instruction-set extensions appear as being a part of the main CPU.
In terms of hardware, the instruction-set extensions are usually implemented in a separate extension module that is tightly coupled to the main CPU via a well defined pin interface. To ensure tight coupling between the extension module and the CPU, the extension module can have access to the main CPU's internal resources, e.g., registers, accumulators and the like.
In contrast to a processor or co-processor, an extension module generally does not have an internal program memory. Rather, the special purpose instructions for the extension module are obtained from the main CPU instruction flow via a pin interface. This arrangement allows scheduling and synchronization of the extension instructions with the CPU instruction set. For example, this arrangement enables cache coherency or other data hazards to be taken into account.
Extension modules commonly have a private pipeline so as to not slow down the main CPU clock. However an extension module may implement multi-cycle instructions that signal a pipeline stall to the main CPU.
Unfortunately, in most cases under the conventional art, such instruction set extensions and the supporting software development tools are designed manually, with a very low degree of automation or support from design tools. Thus, the design of instruction set extensions and the supporting software development tools is generally viewed as a long, skilled-labor-intensive and risky process, requiring numerous highly skilled engineers with specialized processor design knowledge. Such designers are generally required to have a deep understanding of processor architectures, knowledge of hardware description language (HDL) and a good understanding of software tool development.
For example, the conventional art generally requires use of a register transfer level (RTL) design of signal interface and signal timing, an RTL implementation of the data-path and instruction decoder, design of the instruction pipeline, the implementation of functional, cycle and pin accurate simulation models, and the creation of configuration files for a third party software tool-chain.
Other embodiments of the conventional art are capable of automatically generating some or all of the aforementioned design and/or simulation elements. However, such embodiments generally rely upon a description of the extension in RTL, or a meta language characterized as requiring about the same level of design detail as RTL, and requiring about the same level of circuit design expertise as RTL.
Such complexity and technical challenges generally prohibit the most likely target user, a software designer, from creating such custom instructions. For example, it is usually during a software development process, e.g., after at least preliminary design of a system on a chip and simulation of a software application, that opportunities for the benefits of custom instructions become apparent. However, typically software designers do not have the skill set necessary to design and/or implement such extensions. Consequently, for these multiple reasons, the benefits of custom instructions are rarely enjoyed under the conventional art.